Well, strictly, revert is a modifier that you stick on the front of another commit's message.

Can you describe it like that instead?

Since there is only one "modifier", should I just say revert?
I'm not 100% sure how you wanna write it but I'll push up something.

Also I'm maintaining the module conventional-changelog used by you guys.
what do you expect conventional-changelog to do to this? I would simply parse it as a type so it will look the same as other types.

## Bug Fixes
...

## Reverts
...

Well at the moment, we are not actually using your package. Instead we use an script inside the angular.js project, changelog.js. And in this script you can see that we ignore all commits that do not start with fix, feat, perf or contain the word BREAKING. See https://github.com/angular/angular.js/blob/master/changelog.js#L194

The general idea, though, as far I am concerned, is that reverted commits should be removed from the changelog. So assuming that the original commit is also in the current release then we should simply ignore both commits. If it is reverting from a previous release, then I agree that we should have some kind of ## Reverts section.

Yup, that script is actually the very first version of conventional-changelog. You guys should definitely use the package once I release v0.1.x. It's much better :)
I agree with you. So far it's not smart enough to remove both commits within one release. Thanks for the feedback @petebacondarwin

Let me know what you think of the docs.

Things I found about the commit message guide is that it's actually not very strict:

1. It doesn't say what's optional what's not.
2. The exact format of a part.
   For example, it doesn't say how Breaking Changes should be written. The sentense should start with Breaking Change: and there are optional two newlines between Breaking Change: and the content of it.

This applies to the google doc you link to in the file. It gives more examples but still not very strict.

I added two commits just to support my points (Maybe they should be in different PR but they kinda related and I need your opinions). Let me know what you think. Thanks.

ping @petebacondarwin

Fun fact: According to the validate-commit-msg.js file, revert is considered a valid type since Nov 2012 (and there are tests that verify it - which probably no one runs 😃).

hm... lol. conventional-changelog treats revert as a type too (if it reverts a commit that's not in the current release) and it works well. There is no need to make an exceptional rule for it.

for validate-commit-msg.js I think it should verify the reverted commit actually exists.

LGTM!

Thanks @petebacondarwin , @gkalpak anything you would like to add here?

Would be great if you guys could update the docs on google docs
https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

Or, even better, create a git repo just for the conventions?

Thanks @petebacondarwin

@stevemao I have also updated the google doc.

Nice, will check it out